Method for distributing requests to server computers

ABSTRACT

In the method of the invention, requests received by a request distributor are distributed to server computers. The request distributor uses distribution information for selecting, as a destination for the requests, a server computer. A first request relating to a delivery of a service is received by the request distributor and sent to one server computer. The server computer then receives the first request. Finally, it is determined whether a further request relating to the delivery of the service is expected to be received by the request distributor, and, if so, distribution information is made available to the request distributor.

TECHNICAL FIELD

The present invention relates to a method for distributing requestsreceived by a request distributor to server computers. It also relatesto a system, a request distributor and a server computer for carryingsuch a method.

BACKGROUND

Telecommunications networks, such as mobile communications networks, andcomputer networks, such as the Internet, are widely used for remotelyproviding services to terminals accessible by users or customers. Theseterminals are herewith referred to as client terminals while the usersor customers accessing the client terminals are herewith referred to asclient users. The provision of a service is a technical and economicalactivity which may for instance result in the ownership of physicalgoods through a sale.

The provision of a service may for instance be initiated by thetransmission of a request for a service, such as a Hypertext TransferProtocol (HTTP) request through a computer network. The request for aservice is transmitted from a client terminal to a computer systemconfigured for handling the request and for carrying steps to providethe service. After reception of the request, a response thereto may besent by the computer system, which may for instance include a webserver, to the client terminal in order to request more informationinput from the client user or in order to confirm to the client userthat a service or a portion of a service has been successfully provided.

The requests and responses exchanged between the client terminals andthe computer system constitute data communication traffic travelling onnetworks, for instance switched data packet networks. The networks mayinclude routers, which are processing units configured for determiningthe proper path for the requests and responses to travel in thenetworks, and for forwarding the requests and responses to the nextdevice along this path.

In the context of providing a service through a network infrastructure,performance and reliability constitute two requirements.

The performance of a computer network infrastructure may be viewed as ameasure of the quality and responsiveness of the infrastructure forproviding a service as seen from client users. The reliability of acomputer network infrastructure may be viewed as a measure of howreliable the infrastructure is for providing a service, which may forinstance be related to the likelihood that the computer networkinfrastructure fails to provide the service.

Methods exist to improve the performance and reliability of a computernetwork infrastructure or system. One method is to use a configurationor architecture wherein a plurality of server computers are provided inthe system configured for handling the requests for a service. A servercomputer is a computer configured with computer instructions foraccepting connections to service requests and for optionally sendingback responses.

Such a plurality of server computers may be arranged as a cluster ofserver computers with a particular server computer acting as a requestdistributor. More generally, a request distributor refers to a computerentity configured for receiving requests from a network and fordistributing these requests.

As seen from the client users, the system including the cluster ofserver computers and the request distributor can be perceived as asingle computer carrying out actions to respond to the requests andprovide the service. The system includes a plurality of servercomputers, i.e. the cluster of server computers, but it operates in sucha manner that the presence of the cluster is generally not perceived byclient users. The operation of the cluster is generally said to betransparent to the client users.

In order to improve the performance and reliability of the system forproviding the service, the capacity of a server computer cluster may beincreased by increasing the number of server computers in the cluster.Client users substantially see no difference, except the improvedperformance and reliability, since the client terminals exchangerequests and responses only with an access point. The access point mayfor instance be the request distributor or another entity arrangedbetween the client terminals and the request distributor. A certaindegree of transparent scalability is said to be provided when the numberof server computers can be increased while the client userssubstantially see no difference.

Thus, increasing the number of server computers in a cluster, alsocalled server pool or server farm, generally improves reliability andperformance. Reliability is improved by providing redundancy in theevent of the failure of one or more server computers or in the eventthat one or more server computers are temporarily shut down formaintenance. Performance is increased by an increase spreading of therequests amongst the server computers and thus the responsiveness of theserver computers is increased, because a given amount of requests may behandled by more server computers.

The architecture including the cluster of server computers and therequest distributor to receive the requests enables distributed andparallel handling of the service requests.

The request distributor has the function of distributing, ordispatching, the requests to the server computers making up the cluster.

The distribution mechanism for distributing the requests to the servercomputers and for spreading work between them may be a load-balancingmechanism. It may aim at a uniform use of resources across the availableserver computers and may for instance be based on a round robinscheduling mechanism where each server computer receives an equal shareof the requests in turn. The distribution mechanism may be independentof the capacity or status of the server computers, or may instead dependon the hardware or software characteristics of the server computers oron their status or characteristics at a given moment in time, such astheir processing or memory capacity, their response time, or the numberof active connections, i.e. the communication link usage.

Static configuration rules to determine the destination server computermay be used by the request distributor to distribute the requests,depending for instance on the content or type of the requests.

In addition, one or more server computers may be specialized forhandling certain tasks and the static configuration rules may take thisfunctional specialization into account.

The server computers have the function of handling the requeststransmitted from the request distributor. The handling of the requestsenables to provide the service.

The completion of most services involves a plurality of steps to becarried out according to an execution flow. Therefore, contextinformation pertaining to each one of the initiated service deliveryprocesses is needed by the server computer for handling requests. Thestate of the interaction with one client user, i.e. the state in theservice execution flow, needs to be retained and available when andwhere necessary. A service delivery process is a process of providing agiven service to a given client terminal. In addition to retaining thestate of the service delivery process, the context information mayinclude user preferences associated with the handling of the service.

In the context of providing a service through a computer networkinfrastructure, methods exist to retain context information or, in otherwords, to provide persistence.

A first solution to retain context information is to send all requestsrelating to a same service delivery process to a given server computerwhich retains context information for handling these requests. In thissolution, the request distributor may for instance send all requestscoming from the same source, e.g. from a given Internet Protocol (IP)address or a given network access server (NAS), to one server computer.The information about the state of the service delivery process isstored locally in the server computer. That is, upon processing arequest, the server computer keeps necessary information about theservice delivery process. This solution binds a server computer to aclient terminal.

This solution requires that the request distributor is able to recognizethe requests associated with a given service delivery process. However,this is not always possible. In addition, this solution runs counter theprimary advantages of load balancing. This is especially true if, from agiven source such as a given Internet Protocol (IP) address of a networkaccess server (NAS), many requests relating to different deliveries ofservice and coming from different client users are received.

A second solution is to allow all computer servers to access a shareddatabase or shared resources wherein the context information about allexecuting service delivery processes is stored.

This solution introduces the complexity of adding a shared database andaffects the overall system efficiency by requiring extra steps to beimplemented to store (write) and retrieve (read) context informationfrom the shared database.

As a third solution, small tokens such as cookies, which are sent inevery client request and include the indication of the state of theservice delivery process, may be used. In other words, the clientterminal is provided with context information, and upon sending the nextrequest, the client includes the context information. The servercomputer can therefore retrieve the context information from the requestitself.

The third solution requires additional information, i.e. the contextinformation, to be transferred on the network to the client terminal andback to the request distributor and the server computer. This may causean additional load on the network. The solution also involvestransferring context information to the client terminal, a practicewhich involves security issues as sensitive information pertaining tothe system internal operation may then be sent.

The three above-described solutions have each specific problems andgenerally lack flexibility. It is therefore desirable to provide analternative method for distributing requests which solves or partiallysolve the above-mentioned problems.

SUMMARY

Such a method is provided by claim 1. Advantageous embodiments aredescribed in the dependent claims.

In the method, requests received by a request distributor aredistributed to at least two server computers. The request distributor isconfigured to use distribution information for selecting, as adestination for each of at least some of the requests, one of the atleast two server computers, depending on at least one attributeassociated with said each request. The method includes a requestdistributor receiving procedure, a sending procedure, a server computerreceiving procedure, a determining procedure and a providing procedure.The request distributor receiving procedure is a procedure forreceiving, by the request distributor, a first request from a network,wherein the first request relates to a delivery of a service. Thesending procedure is a procedure for sending, by the requestdistributor, the first request to one of the at least two servercomputers. The server computer receiving procedure is a procedure forreceiving, by the one of the at least two server computers, the firstrequest sent by the request distributor. The determining procedure is aprocedure for determining whether a further request relating to thedelivery of the service is expected to be received by the requestdistributor. Finally, the providing procedure is a procedure for makingavailable distribution information to the request distributor if, in thedetermining procedure, a further request relating to the delivery of theservice is determined to be expected to be received by the requestdistributor.

The method enables a dynamic determination by the request distributor ofthe most appropriate server computer to handle a further requestrelating to a given delivery of a service. The determination of thedestination of requests is based on distribution information which ismade available to the request distributor if a further request relatingto a given delivery of a service is expected to be received. The actualstate in a given service execution flow may therefore be taken intoaccount by the server computers to guide the request distributor in itsdistribution task.

The distribution of requests may therefore be tailored by informationmade available to the request distributor on a delivery of service perdelivery of service basis. In other words, for each individual initiateddelivery of a service, specific distribution information may be madeavailable to the request distributor, thus providing increasedoperational flexibility.

In addition, server computers specialized in the cluster for carryingout certain tasks may be used to handle certain requests depending on astate reached in a service execution flow, but also depending on anyparameter specific to a particular execution of a service executionflow, i.e. depending on a particular individual delivery of a service.

In other words, at a given point during the delivery of a service,distribution information may be provided to the request distributor by aserver computer, which has the knowledge about the logic of the service,the service execution flow, the nature of the service and theparticularities of a given delivery of a service. The server computercan therefore make tailored distribution information available to therequest distributor.

The selection of the most appropriate server computer or the mostappropriate set of server computers for handling an expected furtherrequest, and the setting of the most appropriate distribution rules orrouting parameters in the request distributor are therefore improved.

In addition, all requests relating to an individual delivery of aservice are not required to be sent to the same server computer. Neitherdoes the method require the server computer to maintain contextinformation locally. Instead, context information may be maintainedlocally, may be stored in a shared database, or may be passed from oneserver computer to another server computer in charge of handling a nextstep in a service execution flow. This provides more flexibility in thespecialization of the server computers and in the distribution of therequests to the server computers according to dynamically configureddistribution rules in the request distributor.

In one embodiment of the method according to the invention, each initialrequest relating to a service is sent by the request distributor to oneparticular server computer, or to one of a set of particular servercomputers. This particular server computer is, or this set of particularserver computers are, specialized in handling initial requests and inperforming required authentication.

In this embodiment, after the reception and handling of the initialrequest by a particular server computer and after the subsequent initialauthentication, a certain number of exchanges are performed with thatparticular server computer. Once a valid user identity is determined,the server computer makes distribution information available to therequest distributor to instruct said request distributor to redirect anexpected further request to another given specialized server computer.This other specialized server computer may be specialized in handlingsome further steps in the service delivery process.

In another embodiment, an initial Hypertext Transfer Protocol (HTTP) GETrequest is received by the request distributor. A Hypertext TransferProtocol (HTTP) GET request is a request from a view or representationof a specified resource such as a Hypertext Markup Language (HTML) page.The initial request may be a request of a form. The request distributormay then send the request to a default server computer specialized inreturning to client terminals Hypertext Markup Language (HTML) pagesrepresenting forms.

The requested form, to be filled by the client user, is then sent as aresponse to the client terminal through the request distributor. At thesame time, by adding a parameter to the response, the server computerinforms the request distributor of a distribution rule for handlingfurther request relating to the delivery of the service. The furtherrequest, which is expected to be received after a Hypertext TransferProtocol (HTTP) GET request of a form, may be a Hypertext TransferProtocol (HTTP) POST of the form. A Hypertext Transfer Protocol (HTTP)POST request submits data to be processed by a server computer, e.g. thedata associated with the filled form. The specific server computer maybe specialized in handling Hypertext Transfer Protocol (HTTP) POSTrequest, including data associated with a filled form.

In one embodiment, the method is such that the determining procedurefurther includes determining that a response to the first request is tobe sent by the one of the at least two server computers and that thefurther request relating to said service is expected to be received bythe request distributor after the response is sent.

This embodiment enables sending the distribution information from theserver computer to the request distributor with the response to thefirst request, so that the request distributor receives the appropriatedistribution information when transmitting the response from the servercomputer back to the client terminal and before receiving the expectedfurther request from the client terminal.

In one embodiment, the method is such that the distribution informationidentifies that the preferred or assigned destination for the furtherrequest is one of the at least two server computers.

This has the advantage of providing a simple distribution rule for useby the request distributor and an efficient manner for assigningexpected further request to specialized server computers.

In one embodiment, the method is such that the determining procedure isperformed by the one of the at least two server computers.

This has the advantage that the server computer in charge of handling afirst request may determine, based on the first request, i.e. based forinstance on its content and nature, and further based on the knowledgethe server computer has of the service execution flow, whether a furtherrequest is expected or not. The request distributor may thus be providedwith relevant, fine-grained distribution rules. In addition, no trafficis generated and no processing work need be carried out to dynamicallyconfigure the request distributor in the event that no further requestis expected.

In one embodiment, the method is such that the providing procedure isperformed by the one of the at least two server computers.

This has the advantage that the server computer in charge of handling afirst request may determine, based on the first request, i.e. based forinstance on its content and nature, and further based on the knowledgethe server computer has of the service execution flow, what distributioninformation needs to be made available to the request distributor. Therequest distributor may thus be provided with relevant, fine-graineddistribution rules directly transmitted from the server computer.

The invention further consists in a method, carried out by a servercomputer, of making distribution information available to a requestdistributor. In this method, the request distributor is configured toreceive requests from a network, to distribute each one of the requeststo one of the server computer and at least one another server computer,and to use the distribution information for selecting, as a destinationfor each of at least some of the requests, one of the server computerand the at least one another server computer, depending on at least oneattribute associated with said each request. The method includes adetermining procedure for determining, by the server computer, based onat least one of a first request received by the server computer from therequest distributor and associated with a delivery of a service, and theservice, whether a further request relating to the delivery of theservice is expected to be received by the request distributor. Themethod further includes a providing procedure for making available, bythe server computer, the distribution information to the requestdistributor if, in the determining procedure, a further request relatingto the delivery of the service is determined to be expected to bereceived by the request distributor.

The invention further consists in a method, carried out by a requestdistributor, of distributing requests to at least two server computers.In this method, the request distributor is configured to receiverequests from a network and to distribute each one of the requests toone of at least two server computers, and at least one of the at leasttwo server computers is configured to make available distributioninformation to the request distributor. The method includes a receivingprocedure for receiving, by the request distributor, a first requestfrom the network, wherein the first request relates to a delivery of aservice. The method further includes a sending procedure for sending, bythe request distributor, the first request to one of the at least twoserver computers. The receiving procedure further includes receiving, bythe request distributor, a further request relating to the delivery ofthe service. The method further includes a selecting procedure forselecting, by the request distributor, as a destination for the furtherrequest, one of the at least two server computers, by using distributioninformation made available by one of the at least two server computersto the request distributor and depending on at least one attributeassociated with the further request. Finally, the sending procedurefurther includes sending, by the request distributor, the furtherrequest to the server computer selected in the selecting procedure.

The invention further consists in a system including a requestdistributor and at least two server computers. The system is configuredfor distributing request received by the request distributor to the atleast two server computers. Said request distributor is configured touse distribution information for selecting, as a destination for each ofat least some of the requests, one of the at least two server computers,depending on at least one attribute associated with said each request.The system further includes a request distributor receiving unit, asending unit, a server computer receiving unit, a determining unit and aproviding unit. The request distributor receiving unit is configured forreceiving, by the request distributor, a first request from a network,wherein the first request relates to a delivery of a service. Thesending unit is configured for sending, by the request distributor, thefirst request to one of the at least two server computers. The servercomputer receiving unit configured for receiving, by the one of the atleast two server computers, the first request sent by the requestdistributor. The determining unit is configured for determining whethera further request relating to the delivery of the service is expected tobe received by the request distributor. Finally, the providing unit isconfigured for making available distribution information to the requestdistributor if, in the determining unit, a further request relating tothe delivery of the service is determined to be expected to be receivedby the request distributor.

The invention further consists in a server computer configured formaking distribution information available to a request distributor. Saidrequest distributor is configured to receive requests from a network, todistribute each one of the requests to one of the server computer and atleast one another server computer, and to use the distributioninformation for selecting, as a destination for each of at least some ofthe requests, one of the server computer and the at least one anotherserver computer, depending on at least one attribute associated withsaid each request. The server computer includes a determining unitconfigured for determining, based on at least one of a first requestreceived by the server computer from the request distributor andassociated with a delivery of a service, and

the service, whether a further request relating to the delivery of theservice is expected to be received by the request distributor.Furthermore, the server computer includes a providing unit configuredfor making available the distribution information to the requestdistributor if, in the determining unit, a further request relating tothe delivery of the service is determined to be expected to be receivedby the request distributor.

The invention further consists in a request distributor configured fordistributing requests to at least two server computers. Said requestdistributor is configured to receive requests from a network and todistribute each one of the requests to one of at least two servercomputers, and

at least one of the at least two server computers is configured to makeavailable distribution information to the request distributor. Therequest distributor includes a receiving unit configured for receiving afirst request from the network, wherein the first request relates to adelivery of a service. The request distributor further includes asending unit configured for sending the first request to one of the atleast two server computers. The receiving unit is further configured forreceiving a further request relating to the delivery of the service. Therequest distributor further includes a selecting unit configured forselecting as a destination for the further request, one of the at leasttwo server computers, by using distribution information made availableby one of the at least two server computers to the request distributorand depending on at least one attribute associated with the furtherrequest. Finally, the sending unit is further configured for sending, bythe request distributor, the further request to the server computerselected by the selecting unit.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention shall now be described, inconjunction with the appended figures, in which:

FIG. 1 schematically illustrates an embodiment of a networkconfiguration wherein a method according to the invention may be carriedout;

FIG. 2 schematically illustrates an embodiment of a networkconfiguration wherein a method according to the invention may be carriedout and wherein the request distributor includes a plurality of nodes;

FIG. 3 schematically illustrates an embodiment of a networkconfiguration wherein a method according to the invention may be carriedout and wherein a storing means for storing the distribution informationis illustrated;

FIG. 4 schematically illustrates an embodiment of a networkconfiguration wherein a method according to the invention may be carriedout and wherein the server computers are functionally specialized;

FIG. 5 schematically illustrates an embodiment of a networkconfiguration wherein a method according to the invention may be carriedout, wherein the server computers are functionally specialized andwherein the request distributor receives requests from wireless localarea network (WLAN) access points;

FIG. 6 is a flow chart of an embodiment of a method according to theinvention;

FIG. 7 is a flow chart of an embodiment of the determining procedure ofa method according to the invention;

FIG. 8 is a flow chart of an embodiment of the providing procedure of amethod according to the invention;

FIGS. 9 and 10 schematically illustrate embodiments of networkconfigurations wherein a method according to the invention may becarried out and wherein, respectively, distribution information isprovided directly to the request distributor and distributioninformation is made available to a storage means accessible from therequest distributor;

FIG. 11 schematically illustrates a request distributor according to anembodiment of the invention;

FIG. 12 schematically illustrates a server computer according to anembodiment of the invention;

FIGS. 13 a and 13 b are flow charts respectively for a server computerand a request distributor according to one embodiment of the invention;and

FIG. 14 illustrates a method for shutting down a server computeraccording to an embodiment of the invention.

DETAILED DESCRIPTION

The present invention shall now be described in conjunction withspecific embodiments. It may be noted that these specific embodimentsserve to provide the skilled person with a better understanding, but arenot intended to in any way restrict the scope of the invention, which isdefined by the appended claims.

FIG. 1 schematically represents an embodiment of an architecture whereina method of the invention may be performed.

In this architecture, a request distributor 2 is configured to receiverequests for a service from a network 6. The arrow reaching the requestdistributor 2 and coming from the network 6 illustrates the transmissionof requests and their reception by a request distributor 2. The requestsoriginate directly or indirectly from one or more client terminals (notillustrated on FIG. 1). The client terminals are able to be connected toat least one network and able to send requests to the requestdistributor 2. The request distributor 2 is connected to the network 6and able to receive requests transmitted from the network 6. The clientterminals may be connected directly to the network 6. Alternatively theclient terminals may be connected to another network (not illustrated)which is directly, or indirectly through yet other networks (notillustrated), connected to the network 6.

Intermediary network nodes may be added to the architecture, such as afirewall in front of the request distributor 2 to act as a filter toprevent malicious requests from reaching the request distributor 2 or todetect any such malicious requests.

The request distributor 2 is configured to distribute the receivedrequests to one of the server computers 4 a, 4 b. Only two servercomputers 4 a, 4 b are represented in FIG. 1, but more than two servercomputers 4 a, 4 b may be provided. Their number is not limited.

A request distributor 2 is a computer entity configured for receivingrequests from a network 6 and for distributing the requests. A servercomputer 4 a, 4 b is a computer configured with instructions foraccepting connections to service requests and for optionally sendingback responses. Distributing requests to server computers 4 a, 4 b meanssending each one of the requests to at least one server computer 4 a, 4b. In one embodiment, the distribution of requests is implemented bysending each one of the requests to only one server computers 4 a, 4 b.In another embodiment, some of the requests or all requests are sent tomore than one server computers 4 a, 4 b.

A delivery of a service is one or more steps with the intention toobtain or deliver a service. The provision or delivery of a service is atechnical and economical activity which may for instance result in theownership of physical goods through a sale or in the change in theproperties of an asset. A service may be provided according to a serviceexecution flow. A same client terminal may initiate a plurality ofdeliveries of a service. Examples of services include the online processof booking train tickets or buying a book.

The server computers 4 a, 4 b may be equal in functionality or not. Ifthe server computers 4 a, 4 b are not equal in functionality, some ofthem are said to be specialized server computers. For instance, a groupof specialized servers may be dedicated to a particular task or set oftasks, while being provided for instance with a particularinfrastructure, rights, database accesses, or adapted security softwareor hardware configurations. Specializing server computers 4 a, 4 b maybe advantageous to concentrate required software or hardware on certainserver computers and to relieve other server computers from having suchspecialized software or hardware configurations or equipments.Particular policies for handling the requests may also be implemented onsome server computers depending on which type of requests these servercomputers are configured to handle.

In other words, the server computers 4 a, 4 b may either beheterogeneous or homogeneous with respect to their internalarchitecture, capacity, functionality, etc.

The server computers 4 a, 4 b may or may not be tightly coupled, may ormay not trust each other, may or may not be able to directly communicatewith each other, and may or may not be geographically dispersed. In oneembodiment, the server computers 4 a, 4 b of the cluster are tightlycoupled, trust each other, are able to communicate with each other andare geographically located close to each other.

In one embodiment, the server computers 4 a, 4 b are connected to therequest distributor 2 through a local area network (LAN) or a storagearea network (SAN) so as to be able to efficiently receive requests fromthe request distributor 2, and to efficiently make availabledistribution information to a request distributor 2.

In one embodiment, the request distributor 2 has an Internet Protocol(IP) address and Internet Protocol (IP) port. The invention is howevernot limited to a particular communication protocol.

FIG. 2 schematically illustrates a configuration wherein the requestdistributor 2 is made up of a plurality of network nodes 8, which may beat the same location or geographically dispersed. The network nodes 8efficiently provide a service to client users which may located indifferent locations, since a network node 8 of the request distributor 2may be located in their area.

In the embodiment illustrated in FIG. 2, the providing procedure 20 mayinvolve making available distribution information to all the networknodes 8 making up the request distributor 2.

Alternatively, the providing procedure 20 may involve making availabledistribution information only to one or some of the network nodes 8.Simplification of the request distributor 2 internal structure may beobtained by only making available the distribution information to one orsome of its network nodes 8.

If, after a first request relating to a delivery of a service, a furtherrequest relating to the delivery of the service is received by a networknode 8 of the request distributor 2 and this network node 8 has accessto the distribution information, the request distributor 2, via theoperation of one of its network node 8, may use this distributioninformation to select a destination server computer 4 a, 4 b. Thisprovides fine-grained and versatile distribution.

Otherwise, in the event that a further request relating the delivery ofthe service is received by a network node 8 of the request distributor 2and this network node 8 has no access to the distribution informationmade available to the request distributor 2 for distributing therequest, the request distributor 2, via the operation of one of itsnetwork node 8, may select a destination server computer 4 a, 4 baccording to a default distribution rule. For instance, in that case,the request distributor 2 may send the request to a default servercomputer 4 a, 4 b and a mechanism may be provided in the default servercomputer 4 a, 4 b for recovering the context information associated withthe delivery of the service associated with the received request. Thisprovides simplification on the request distributor side.

Alternatively, the request distributor 2 may include one network nodeonly.

FIG. 3 schematically illustrates a configuration according to oneembodiment of the invention, wherein a storage means 10, for instance adatabase, is accessible to the request distributor 2. All or a part ofthe distribution information made available in the providing procedure10 to the request distributor 2 may be made available in this storagemeans 10 for use by the request distributor 2.

In one embodiment, the storage means 10 is a Lightweight DirectoryAccess Protocol (LDAP) compliant directory. The storage means 10 mayalso for instance be a text file or a database.

FIG. 4 schematically illustrates a configuration according to oneembodiment of the invention, wherein some of or all the server computers4 a, 4 b, 4 are functionally specialized. For instance, the two servercomputers 4 a, 4 represented on the right bottom of FIG. 4 with a smallillustrative key label may be specialized in performing authenticationprocedures. These server computers 4 a, 4 may be in charge of handlinginitial service requests for authenticating a client user during adelivery of a service.

The distribution information made available to the request distributor 2may take advantage of this server computer specialization. A servercomputer 4 a, 4 b, 4, having received a first request relating to adelivery of a service, may determine, depending on the particulars ofthe individual delivery of the service, that a further request is to besent to another specialized server computer having for instance aparticular hardware, such as a particularly large storage capacity, aparticularly secure storage, a particularly powerful processing unit,particular processing means, a particular software configuration, suchas available cryptographic functions, or being in a particular virtuallocal area network (VLAN) for traffic separation reasons.

FIG. 5 schematically illustrates a configuration according to oneembodiment of the invention, wherein different client terminals 30 sendrequests to the request distributor 2 through different networks 6 anddifferent access point 28. One access point may be a wireless local areanetwork (WLAN) access point 28 providing access from a wireless localarea network (WLAN) 6 to which terminals 30, for instance computers orlaptops, are connected. Another access point may be a base station 28providing access from a radio access network 6 to which terminals 30,for instance mobile communication terminals, are connected.

FIG. 6 represents a flow chart of an embodiment of a method according tothe invention. A series of procedures are provided and are intended tobe carried out consecutively.

First, a request distributor receiving procedure 12 provides steps andinstructions to be carried out by a request distributor 2 for receivinga request from a client terminal 30 through a network 6. This may be afirst request relating to a delivery of a service or a further requestrelating to the delivery of the service.

Then, a sending procedure 14 is provided for, after reception of arequest, sending the request to a server computer 4 a, 4 b, 4.

A server computer receiving procedure 16 is then provided for receiving,by the server computer 4 a, 4 b, 4, the request sent by the requestdistributor 2.

The server computer 4 a, 4 b, 4 determines, according to a determiningprocedure 18, whether a further request relating to the same delivery ofthe service is expected. The determining procedure 18 may for instancebe based on at least one of the first request associated with a deliveryof a service, the service, the type of the service, the nature of theservice, the characteristics of the service, the properties of theservice, and the reached stage in the delivery of the service.

If a further request relating to the delivery of the service isdetermined to be expected to be received, then distribution informationis made available to the request distributor 2, according to a providingprocedure 20. The request distributor 2 is configured to use thedistribution information to later select the destination server computer4 a, 4 b, 4 of a request depending on at least one attribute associatedwith the request. The distribution information may be parameters forrouting policies configured in the request distributor 2 or thedistribution information may be the routing policies themselves.

In one embodiment of a providing procedure 20, a server computer 4 a, 4b, 4 having received a request from a client terminal 30 and havingdetermined that a response is to be sent to the client terminal 30, addsto the response to the request a specific attribute, parameter, orheading, etc that has to be transmitted only between the server computer4 a, 4 b, 4 and the request distributor 2. The response is sent by theserver computer 4 a, 4 b, 4 to the request distributor 2.

The request distributor 2, having received the response to be handledand forwarded to the client terminal 30, may then optionally remove thespecific attribute, parameter, heading, etc before sending the serviceresponse to the client terminal 30. Removing, by the request distributor2, the specific attribute, parameter, or heading, etc before forwardingthe response to the client terminal 30 improves the security, privacyand transparency of the method, in that the client terminal 30 is notprovided with information about the internal structure and operation ofthe system.

In another embodiment of a providing procedure 20, a server computer 4a, 4 b, 4 adds specific information to a standard attribute, parameter,heading, etc which content has a special meaning to the requestdistributor 2. No modification is therefore required to an existingcommunication protocol for communicating between a server computer 4 a,4 b, 4 and a request distributor 2. The request distributor 2 may thenoptionally remove the added information before sending the serviceresponse to the client terminal 30, thus increasing privacy, securityand transparency.

In yet another embodiment of a providing procedure 20, a server computer4 a, 4 b, 4 may re-use a standard attribute with its standardinformation in such a manner that the request distributor 2 is able tointerpret the content in a specific way. The client terminal 30 may beaware of the attribute existence and its content but not of how theattribute is interpreted by the request distributor 30, thus ensuring acertain degree of privacy, security, and transparency.

In a further embodiment of a providing procedure 20, distributioninformation is sent using a different and specific interface between theserver computer 4 a, 4 b, 4 and the request distributor 2. The interfacemay be based for instance on the Lightweight Directory Access Protocol(LDAP), or the Common Open Policy Service (COPS) Protocol, a part of theInternet protocol suite as defined by the Internet Engineering TaskForce (IETF) Request for Comments RFC 2748.

In one embodiment of a method of the invention, one of the determiningprocedure 18 and the providing procedure 20, or both, are carried out byanother physical entity than a server computer 4 a, 4 b, 4.

In one embodiment, the sending procedure 14 is also used to send, by therequest distributor 2, a further request to a selected destinationserver computer 4 a, 4 b, 4, once an expected further request isreceived by the request distributor 2 and once, according to a selectingprocedure, the request distributor 2 has selected a destination servercomputer 4 a, 4 b, 4 by using distribution information made available tothe request distributor 2 and depending on at least one attributedassociated with the further request.

FIG. 7 represents a flowchart of an embodiment of a determiningprocedure 18 of a method according to the invention, wherein it isdetermined 22, for instance by the server computer 4 a, 4 b, 4, not onlythat a further request relating to the delivery of the service isexpected to be received by the request distributor 2 but also that aresponse is to be sent first to the client terminal 30 before thefurther request can be expected to be received by the requestdistributor 2.

FIG. 8 represents a flowchart of an embodiment of a providing procedure20 of a method according to the invention, wherein distributioninformation is made available to the request distributor 2, for instanceby the server computer 4 a, 4 b, 4, and wherein the distributioninformation identifies a destination server computer 4 a, 4 b, 4 for theexpected further request relating to the delivery of the service. Theidentified destination server computer 4 a, 4 b, 4 may be the same asthe server computer 4 a, 4 b, 4 to which the first request was sent ormay be another one. In the latter case, context information may bepassed from the server computer 4 a, 4 b, 4 to which the first requestwas sent to the identified destination computer server 4 a, 4 b, 4 forproper handling of the service. Reference 24 in FIG. 8 refers to thecreation of the distribution information for identifying the destinationserver computer 4 a, 4 b, 4.

FIG. 9 schematically illustrates a configuration according to oneembodiment of the invention, which is similar to the configurationillustrated in FIG. 1 except that a server computer 4 a makes available,in the providing procedure 20, the distribution information by directlyproviding it to the request distributor 2. This providing step isillustrated by the arrow going from the server computer 4 a to therequest distributor 2.

FIG. 10 schematically illustrates a configuration according to oneembodiment of the invention, which is similar to the configuration ofFIG. 1 except that a server computer 4 a makes available, in theproviding procedure 20, the distribution information by storing it in astorage means 10 accessible by the request distributor 2. This providingstep is illustrated by the arrow going from the server computer 4 a tothe storage means 10.

FIG. 11 schematically represents a request distributor 2 according toone embodiment of the invention.

The request distributor 2 includes a request distributor receiving unit112, or more generally request distributor receiving means, configuredfor performing the request distributor receiving procedure 12 describedwith reference to FIG. 6.

The request distributor 2 also includes a sending unit 114, or moregenerally sending means, configured for performing a sending procedure14 described with reference to FIG. 6.

Furthermore, the request distributor 2 includes a selecting unit 126, ormore generally selecting means, configured for selecting as adestination for the further request one of the at least two servercomputers 4 a, 4 b, 4. The selecting unit 126, or the selecting means,uses, on the one hand, distribution information made available by one ofthe at least two server computers 4 a, 4 b, 4 to the request distributor2 and, on the other hand, at least one attribute associated with thefurther request, i.e. an attribute retrievable from the further requestby the request distributor 2.

FIG. 12 schematically represents a server computer 4 a according to oneembodiment of the invention.

The server computer 4 a comprises a server computer receiving unit 116,or more generally server computer receiving means, configured forperforming the server computer receiving procedure 16 described withreference to FIG. 6.

In one embodiment, the server computer 4 a also comprises a determiningunit 118 (dotted line), or more generally determining means, configuredfor performing, by the server computer 4 a, the determining procedure 18described with reference to FIG. 6, and a providing unit 120 (dottedline), or more generally providing means, configured for performing, bythe server computer 4 a, the providing procedure 20 described withreference to FIG. 6.

In one embodiment, these two units, i.e. the determining unit 118 andthe providing unit 120, are not included in a server computer 4 a, butare arranged elsewhere.

FIGS. 13 a and 13 b are flow charts respectively illustrating theoperations of a server computer 4 a, 4 b, 4 a and a request distributor2 according to one embodiment of the invention.

In this embodiment and with reference to FIG. 13 a, the server or servercomputer 4 a, 4 b, 4 receives (reference 1 in FIG. 13 a) a servicerequest, i.e. a request for a delivery of a service, executes, i.e.handles, said request, and determines, for instance according to aservice execution flow, if there is a known next expected servicerequest, i.e. a further request relating to the delivery of the service.

If a next service request or further request exists and is expected, theserver computer 4 a, 4 b, 4 determines if there is a most appropriateserver computer 4 a, 4 b, 4 for handling the next service request orfurther request, and if there is a most appropriate distribution rulefor handling this next service request or further request. If there is amost appropriate server computer 4 a, 4 b, 4 and/or a most appropriatedistribution rule, the server computer 4 a, 4 b, 4 responds (reference 2b 1 in FIG. 13 a) to the request and makes available (reference 2 b 2 inFIG. 13 a) distribution information to the request distributor 2. Thesteps of responding (2 b 1) to the request and making available (2 b 2)distribution information to the request distributor 2 may be combined.

If no next service request or further request exists and is expected orif there is no most appropriate server computer 4 a, 4 b, 4 and no mostappropriate distribution rule, the server computer 4 a, 4 b, 4 responds(reference 2 a in FIG. 13 a)

Still in this embodiment and with reference to FIG. 13 b, top flowchart, the request distributor 2 receives a service request from thenetwork 6. The request distributor 2 then determines whether dynamicserver-instructed policies exist in relation to this service request. Inother words, the request distributor 2 determines whether distributioninformation is available for handling the received request.

If yes, i.e. if distribution information is available for handling thereceived request, the specific location rule or distribution policy isexecuted to select the destination server computer 4 a, 4 b, 4. If theselected destination server computer 4 a, 4 b, 4 cannot be located, astandard distribution rule is executed and applied to select anotherserver computer 4 a, 4 b, 4 and the request is forwarded (reference 1 inFIG. 13 b) to the selected another destination server computer 4 a, 4 b,4. Otherwise, if the selected destination server computer 4 a, 4 b, 4can be found, the request is forwarded (reference 1 in FIG. 13 b) tosaid selected destination server computer 4 a, 4 b, 4.

If no, i.e. if distribution information is not available for handlingthe received request, a standard distribution rule is executed andapplied to select a destination server computer 4 a, 4 b, 4 and therequest is forwarded (reference 1 in FIG. 13 b) to the selecteddestination server computer 4 a, 4 b, 4.

Still in this embodiment and with reference to FIG. 13 b, centre flowchart, if a service answer or response to a request is received(reference 2 a and 2 b 1 in FIG. 13 b) by the request distributor 2 froma server computer 4 a, 4 b, 4, then a service answer or response to arequest is forwarded by the request distributor 2 to the client terminal30.

With reference to FIG. 13 b, bottom flow chart, if a rule configurationor distribution information is received (reference 2 b 2 in FIG. 13 b)by the request distributor 2, the rule configuration or distributioninformation is stored so as to be subsequently used for distributingfurther received requests.

The step of receiving 2 a, 2 b 1 a service answer or response to arequest and the step of receiving 2 b 2 a rule configuration ordistribution information may be carried out in combination.

In one embodiment, a method of the invention is applied in a wirelesslocal area network (WLAN) configuration implementing an authenticationsystem based on EAP-SIM or EAP-AKA over RADIUS.

EAP stands for Extensible Authentication Protocol. It is anauthentication framework used in wireless networks and point-to-pointconnections. It is defined by RFC 3748 (Ababa, E., Blunk, L.,Vollbrechtand, J., Carlson, J., and H. Levkowetz, Ed. “ExtensibleAuthentication Protocol (EAP)”, IETF RFC 3748, June 2004).

EAP-SIM stands for EAP for GSM Subscriber Identity and is used forauthentication and session key distribution using the Global System forMobile Communications (GSM) Subscriber Identity Module (SIM). EAP-SIM isdefined in RFC 4186 (H. Haverinen, and J. Salowey, “ExtensibleAuthentication Protocol Method for Global System for MobileCommunications (GSM) Subscriber Identity Modules (EAP-SIM)”, IETF RFC4186, January 2006).

EAP-AKA stands for EAP for UMTS Authentication and Key Agreement and isused for authentication and session key distribution using the UniversalMobile Telecommunications System (UMTS) UMTS Subscriber Identity Module(USIM). EAP AKA is defined in RFC 4187 (J. Arkko, H. Haverinen,“Extensible Authentication Protocol Method for 3rd GenerationAuthentication and Key Agreement (EAP-AKA)”, IETF RFC 4187, January2006).

EAP-SIM and EAP-AKA are authentication mechanisms complying with the EAPframework.

Remote Authentication Dial In User Service (RADIUS) is a securityauthentication and authorization protocol enabling a network accessserver to authenticate its links. RADIUS is defined in RFC 2865 (C.Rigney, S. Willens, A. Rubens, W. Simpson, “Remote Authentication DialIn User Service (RADIUS)”, IETF RFC 2865, June 2000).

In this embodiment, client terminals 30 exchange requests and responseswith an authentication server through a subscription locator function(SLF). The authentication server is a type of server computer 4 a, 4 b,4 according to the invention. The subscription locator function (SLF) isa type of request distributor 2 according to the invention.

There are several authentication servers, each one being a servercomputer 4 a, 4 b, 4.

The exchanges of requests and responses between client terminals 30 andauthentication servers are encapsulated into the RADIUS protocol fortheir transport through the network 6 and from the subscription locatorfunction (SLF) (request distributor 2) and the authentication server(server computer 4 a, 4 b, 4). Since the exchange is encapsulated intoRADIUS, the subscription locator function (SLF) cannot retrieve the useridentity.

Even though in principle the subscription locator function (SLF) couldbe modified and could become highly specialized to be able to obtain EAPlevel information, this is not the case for existing subscriptionlocator functions (SLF). In addition, even if the subscription locatorfunction (SLF) could obtain a user identity, the identity could be atemporary one, unknown to the subscription locator function (SLF), dueto the identity privacy support in EAP-SIM/AKA. Finally, even ifidentity privacy was not used, or if the subscription locator function(SLF) had means to obtain the user permanent identity from the temporaryones, not all EAP-SIM/AKA exchanges carry the user identity, andtherefore the subscription locator function (SLF) would need additionalmeans to track exchanges belonging to a given authentication procedure.

In this embodiment, an authentication procedure comprises severalauthentication requests initiated by the wireless local area network(KLAN) client terminals 30 that are trying to get access to the wirelesslocal area network (WLAN), and the corresponding responses are sent bythe authentication server (server computer 4 a, 4 b, 4).

EAP-SIM/AKA exchanges are processed end-to-end in the wireless localarea network (WLAN) client and the authentication server 4 a, 4 b, 4.Between the wireless local area network (WLAN) access point 28 and theauthentication server 4 a, 4 b, 4, EAP-SIM/AKA exchanges areencapsulated in RADIUS for their transport through the network, with thewireless local area network (WLAN) access point 28 acting as RADIUSclient and the authentication server 4 a, 4 b, 4 acting as RADIUSserver.

The request distributor 2 is not able to recognize the authenticationrequest as a response to a challenge. Having that ability in the requestdistributor 2 would require interpreting the message contents up to EAPlevel, which is not possible for known traffic distributors.

Even if a request distributor 2 was able to recognize the authenticationrequest as a response to a challenge, the request distributor 2 wouldhave no information for selecting the authentication servers 4 a, 4 b, 4with the ability to handle authentication vectors (AVs) and with theability to check the response (i.e. the one that generated thechallenge).

In order to solve this problem in this embodiment, all theauthentication requests corresponding to a given authenticationprocedure are sent to the same authentication server 4 a, 4 b, 4 whichlocally keeps the necessary context information.

In more details, the request distributor 2 receives the firstauthentication request for an authentication procedure, transported in aRADIUS Access-Request message. Since the request distributor 2 has notreceived any specific indication from a server computer 4 a, 4 b, 4applicable to that authentication request, the request distributor 2applies a generic rule for the selection of a destination servercomputer 4 a, 4 b, 4 (e.g. applying round robin distribution), and itforwards the request to that server computer 4 a, 4 b, 4.

The selected server computer 4 a, 4 b, 4 receives the request andprocesses it. As a result of the processing, the server computer 4 a, 4b, 4 may determine that further information (e.g. a suitable useridentity) is required from the client terminal 30 (e.g. a user equipmentor UE), or the server computer 4 a, 4 b, 4 may directly send anauthentication challenge to the client terminal 30. In both cases, theserver computer 4 a, 4 b, 4 sends an EAP-Request to the client terminal30, encapsulated in a RADIUS Access-Challenge. Since the server computer4 a, 4 b, 4 has context information to process subsequent messages fromthe client terminal 30 related to the authentication procedure, theserver computer 4 a, 4 b, 4 may select itself as the most suitableserver computer 4 a, 4 b, 4 to handle the subsequent messages.

In order to indicate this to the request distributor 2, the servercomputer 4 a, 4 b, 4 generates a value, for instance unique, andincludes it in the RADIUS state attribute within the RADIUSAccess-Challenge sent back to the request distributor 2. A standardattribute is therefore re-used with its standard information in such amanner that the request distributor 2 may interpret the content in aspecific manner.

The request distributor 2 receives the RADIUS Access-Challenge, and aspart of its rule configuration procedure, it checks that the RADIUSstate attribute has been included.

The distribution information received via the RADIUS state attribute mayfor instance constitute parameters pertaining to routing policiesconfigured in the request distributor 2. In this case, the configuredrouting policies may require that subsequent requests containing thesame value in the RADIUS state attribute are directed to the servercomputer 4 a, 4 b, 4 from which that value was initially received.

Therefore, a rule is setup in the request distributor 2 so thatsubsequent requests containing a RADIUS state attribute with the samevalue as received from the server computer 4 a, 4 b, 4 are directed tothe server computer 4 a, 4 b, 4.

The RADIUS Access-Challenge is sent back towards the WLAN access point28, which in turn passes the encapsulated EAP-Request to the clientterminal 30.

Upon receiving a response from the client terminal 30, the WLAN accesspoint 28 encapsulates the response in a new RADIUS Access-Request, whichis sent to the request distributor 2. According to the RADIUS protocolspecification, the WLAN access point 28 includes the RADIUS stateattribute in the RADIUS Access-Request message, with the same value asreceived in the previous RADIUS Access-Challenge.

When the request distributor 2 receives the RADIUS Access-Request, itdetermines that the RADIUS state attribute is present and that there isa server-instructed rule providing that any received requests containingthat value in the RADIUS state attribute is to be sent to a given servercomputer 4 a, 4 b, 4. The request distributor 2 then forwards the RADIUSAccess-Request to that given server computer 4 a, 4 b, 4.

The server computer 4 a, 4 b, 4 then receives the new RADIUSAccess-Request and processes it.

If more roundtrips are needed, a new RADIUS Access-Challenge is sent tothe request distributor 2, containing the same RADIUS state attribute.This time, the request distributor 2 need not setting up a new rule,since it has been already created, so that subsequent RADIUSAccess-Requests are sent to the same server computer 4 a, 4 b, 4.

Eventually, the server computer 4 a, 4 b, 4 determines that the user isauthenticated, and a RADIUS Access-Accept is sent back to the requestdistributor 2, containing the same RADIUS state attribute. The RADIUSAccess-Accept is finally sent back to the WLAN access point 28, whichthen grants WLAN access to the client terminal 30.

In addition to what precedes, authentication server computers 4 a, 4 b,4 may be specialized for handling authentication vectors. In this case,in one embodiment of a method according the invention, when theauthentication procedure reaches the point that a challenge forauthentication is sent to the client terminal 30, which requireshandling of authentication vectors, the method could be as follows.

When the initially assigned server computers 4 a, 4 b, 4 determines thata challenge has to be sent to the client terminal 30, it passes thenecessary context information to one specialized authentication servercomputers 4 a, 4 b, 4. The authentication server computers 4 a, 4 b, 4then produces the challenge and sends it back to the request distributor2, encapsulated in a RADIUS Access-Challenge that contains the sameRADIUS state attribute as in previous roundtrips.

The request distributor 2 receives the RADIUS Access-Challenge, and, aspart of its rule configuration procedure, it determines that a RADIUSstate attribute has been included, and that the RADIUS state attributematches one of the existing server-instructed rules. Since the servercomputer 4 a, 4 b, 4 has changed, the request distributor 2 updates theexisting rule so that subsequent requests containing that value in theRADIUS state attribute are directed to the new, specialized servercomputer 4 a, 4 b, 4. The subsequent processing is then the same asdescribed above.

In a further embodiment, when receiving the RADIUS Access-Accept, therequest distributor 2 determines that the server-instructed ruleassociated to that RADIUS state attribute is no longer valid and that arule clear up is to be performed. The distribution information madeavailable to the request distributor 2 may be capable of being clearedup.

The rule clear up may be carried out by using a proprietary RADIUSattribute included by the server computer 4 a, 4 b, 4 in the RADIUSAccess-Accept, and by configuring the request distributor 2 so that itinterprets this attribute as an indication that the previouslyinstructed rule is no longer valid. The request distributor 2 may thenremove the proprietary attribute from the RADIUS Access-Accept beforeforwarding it to the WLAN access point 28.

The rule clear up may be also carried out by using a timeout mechanismin the request distributor 2 so that if a server-instructed rule ordistribution information is not used for a period of time, then thatrule or information is removed.

In a further embodiment, the providing procedure 20 is initiated by anoperator command. The operator command may be a command to shutdown ofone server computer 4 a, 4 b, 4, such as the server computer 4 a, 4 b, 4to which a first request relating to the delivery of the process hasbeen sent. This enables to quickly inform the request distributor 2 thata server computer 4 a, 4 b, 4 is not available anymore for handlingrequests.

In one embodiment of the invention, a shutdown of a server computer 4 a,4 b, 4 may be performed in a graceful manner thanks to the method,system, request distributor 2 and server computer 4 a, 4 b, 4 accordingto the invention. This involves sending a notice to the requestdistributor 2, indicating to the request distributor 2 that a particularserver computer 4 a, 4 b, 4 needs to be shutdown, for whatever reason,be it for maintenance or any other reason. This embodiment isillustrated in FIG. 14.

Due to network maintenance procedures (e.g. hardware or softwareupdates), it is sometimes required to take one of the server computers 4a, 4 b, 4 of a server cluster or pool out of service, so that theremaining servers 4 a, 4 b, 4 handle the traffic while the stoppedserver 4 a, 4 b, 4 is updated, until it is finally put back intoservice.

If the affected server 4 a, 4 b, 4 is directly put out of service, itimplies that all ongoing transactions fail, thus causing a servicedisruption.

In order to alleviate this, a node-level procedure may be used so that,when graceful shutdown is initiated by an operation and maintenancecommand, the server computer 4 a, 4 b, 4 rejects all new requests,although it completes the ongoing ones (i.e. those that are beingprocessed at that moment), and, when these are completed, the servercomputer 4 a, 4 b, 4 is shutdown.

This procedure has limitations. Some transactions are rejected as soonas a graceful shutdown procedure is initiated and until the node iseffectively taken out of service so that no new transactions aredirected to it during a period of time which may be long. In a wirelesslocal area network (WLAN) context, a server computer 4 a, 4 b, 4 couldcomplete a transaction that implies sending an authentication challengeto the client terminal 30, but, if the server computer 4 a, 4 b, 4 isthen shutdown, it may not be possible anymore to determine thecorrectness of the response subsequently sent by the client terminal 30,and the authentication may fail.

In order to avoid service disruption associated with a shutdown, amethod according to one embodiment of the invention is as follows.

When shutdown is initiated by an operation and maintenance command, theserver computer 4 a, 4 b, 4 determines that it is not an appropriateserver computer 4 a, 4 b, 4 for subsequent initial service requests. Inorder to indicate this to the request distributor 2, the server computer4 a, 4 b, 4 may send an instruction to the request distributor 2, e.g.using the Lightweight Directory Access Protocol (LDAP). In order words,the server computer 4 a, 4 b, 4 may make distribution informationavailable to the request distributor 2 with the specific aim to instructit 2 to stop sending requests to said server computer 4 a, 4 b, 4.

When receiving the sent instruction, the request distributor 2 sets up arule so that initial service requests are no longer sent to the affectedserver computer 4 a, 4 b, 4.

In the above-described wireless local area network (WLAN) context, withthis new rule a RADIUS Access-Request would only be sent to the affectedserver computer 4 a, 4 b, 4 if the message contains a RADIUS stateattribute for which there exists a server-instructed rule (previouslyset up by the affected server computer 4 a, 4 b, 4) directing the RADIUSAccess-Request to that server.

As a result, service requests associated to service executions that wereinitiated before the graceful shutdown command are still directed to theaffected server computer 4 a, 4 b, 4 if needed, so that those serviceexecutions can be completed.

Then, when the server computer 4 a, 4 b, 4 has completed all pendingservice executions, it shutdowns.

When the server computer 4 a, 4 b, 4 is put back into service, this isindicated to the request distributor 2, e.g. using the LightweightDirectory Access Protocol (LDAP).

When receiving this indication, the request distributor 2 removes thepreviously created rule, so that initial service requests can now besent to the affected server computer 4 a, 4 b, 4.

FIG. 14 shows a corresponding RADIUS flow, illustrating theconfiguration and operation of the request distributor 2 in thisembodiment of the invention, the configuration of the server computers 4a, 4 b, 4, the dynamic rules and rules execution in the requestdistributor 2 (in FIG. 14, TD stands for traffic distributor). Dynamicrules are configured in two ways, through an LDAP ADD command to therequest distributor 2 or through the state parameter included in theRADIUS operation.

In FIG. 14, only the RADIUS operations are shown for clarity. Insideevery RADIUS operation an EAP information unit is included with theneeded data to execute the EAP service, in this case, and the SAP AKAauthentication service.

A typical EAP-AKA authentication scenario is as follows. First, anaccess point 28 sends a RADIUS Access Request including anRAP-response-identity information unit received from the EAP client. TheEAP server 4 a, 4 b, 4 sends back a RADIUS Access Challenge including anEAP-request-AKA-challenge. The access point 28 sends back theEAP-request to the EAP client. The access point 28 sends a RADIUS AccessRequest including an EAP-response-AKA-challenge received from the EAPclient. Finally the EAP server 4 a, 4 b, 4 sends back a RADIUS AccessAccept including an EAP-success that the access point 28 sends back tothe EAP client.

The physical entities of the system according to the invention,including the request distributor 2 and the server computer 4 a, 4 b, 4may comprise or store computer programs including instructions suchthat, when the computer programs are executed on the physical entities,steps and procedures according to one embodiment of the invention arecarried out. The invention also relates to such computer programs forcarrying out methods according to the invention, and to anycomputer-readable medium storing the computer programs for carrying outmethods according to the invention.

Although the present invention has been described on the basis ofdetailed examples, the detailed examples only serve to provide theskilled person with a better understanding, and are not intended tolimit the scope of the invention. The scope of the invention is muchrather defined by the appended claims.

1. A method for distributing requests received by a request distributor to at least two server computers, wherein the request distributor is configured to use distribution information for selecting, as a destination for each of at least some of the requests, one of the at least two server computers, depending on at least one attribute associated with said each request, the method including: a request distributor receiving procedure for receiving, by the request distributor, a first request from a network, wherein the first request relates to a delivery of a service; a sending procedure for sending, by the request distributor, the first request to one of the at least two server computers; a server computer receiving procedure for receiving, by the one of the at least two server computers, the first request sent by the request distributor; a determining procedure for determining whether a further request relating to the delivery of the service is expected to be received by the request distributor; and a providing procedure for making available distribution information to the request distributor if, in the determining procedure, a further request relating to the delivery of the service is determined to be expected to be received by the request distributor.
 2. The method of claim 1, wherein the request distributor is a network node.
 3. The method of claim 1, wherein the request distributor includes a plurality of network nodes.
 4. The method according to claim 1, wherein the determining procedure further includes determining that a response to the first request is to be sent by the one of at least two server computers and that the further request relating to said service is expected to be received by the request distributor after the response is sent.
 5. The method according to claim 1, wherein the distribution information identifies that the preferred or assigned destination for the further request is one of the at least two server computers.
 6. The method according to claim 1, wherein the determining procedure is performed by the one of the at least two server computers.
 7. The method according to claim 1, wherein the determining procedure is based on at least one of: the first request, the service, the type of service, the characteristics of the service, and the reached stage in the delivery of the service.
 8. The method according to claim 1, wherein the providing procedure is performed by the one of the at least two server computers.
 9. The method according to claim 1, wherein the providing procedure includes providing the distribution information to the request distributor.
 10. The method according to claim 1, wherein the providing procedure includes storing the distribution information in a storing means accessible by the request distributor.
 11. The method of claim 10, wherein the storing means is a Lightweight Directory Access Protocol compliant directory.
 12. The method according to claim 1, wherein the providing procedure is initiated by an operator command.
 13. The method of claim 12, wherein the operator command is a command to shutdown the one of the at least two server computers.
 14. A method, carried out by a server computer, of making distribution information available to a request distributor, wherein the request distributor is configured to receive requests from a network, to distribute each one of the requests to the server computer and at least one another server computer, and to use the distribution information for selecting, as a destination for each of at least some of the requests, one of the server computer and the at least one another server computer depending on at least one attribute associated with said each request, the method including: a determining procedure for determining, by the server computer whether a further request relating to the delivery of the service is expected to be received by the request distributor; and a providing procedure for making available, by the server computer, the distribution information to the request distributor if, in the determining procedure, a further request relating to the delivery of the service is determined to be expected to be received by the request distributor.
 15. The method of claim 14, wherein the determining procedure further includes determining, by the server computer, that a response to a first request is to be sent by the server computer and that the further request relating to said service is expected to be received by the request distributor after the response is sent.
 16. The method according to claim 14, wherein the distribution information identifies that the preferred or assigned destination for the further request is one of the server computer and the at least one another server computer.
 17. The method according to claim 14, wherein the determining procedure is based on at least one of: the first request, the service, the type of service, the characteristics of the service, and the reached stage in the delivery of the service.
 18. The method according to claim 14, wherein the providing procedure includes providing the distribution information to the request distributor.
 19. The method according to claim 14, wherein the providing procedure includes storing the distribution information in a storing means accessible by the request distributor.
 20. The method of claim 19, wherein the storing means is a Lightweight Directory Access Protocol compliant directory.
 21. The method according to claim 14, wherein the providing procedure is initiated by an operator command.
 22. The method of claim 21, wherein the operator command is a command to shutdown the server computer.
 23. A method, carried out by a request distributor, of distributing requests to at least two server computers, wherein the request distributor is configured to receive requests from a network and to distribute each one of the requests to one of at least two server computers, and at least the one of the at least two server computers is configured to make available distribution information to the request distributor, the method including: a receiving procedure for receiving, by the request distributor, a first request from the network, wherein the first request relates to a delivery of a service; a sending procedure for sending, by the request distributor, the first request to one of the at least two server computers; the receiving procedure further including receiving, by the request distributor, a further request relating to the delivery of the service; a selecting procedure for selecting, by the request distributor, as a destination for the further request, one of the at least two server computers, by using distribution information made available by one of the at least two server computers to the request distributor and depending on at least one attribute associated with the further request; and the sending procedure further including sending, by the request distributor, the further request to the server computer selected in the selecting procedure.
 24. The method of claim 23, wherein the distribution information identifies that the preferred or assigned destination for the further request is one of the at least two server computers.
 25. The method of claim 23, wherein, in the selecting procedure, using distribution information made available by one of the at least two server computers to the request distributor includes using distribution information provided by one of the at least two server computers to the request distributor.
 26. The method according to claim 23, wherein, in the selecting procedure, using distribution information made available by one of the at least two server computers to the request distributor includes using distribution information stored in a storing means accessible by the request distributor.
 27. A system including a request distributor and at least two server computers the system being configured for distributing request received by the request distributor to the at least two server computers, wherein the request distributor is configured to use distribution information for selecting, as a destination for each of at least some of the requests, one of the at least two server computers, depending on at least one attribute associated with said each request, the system further including: a request distributor receiving unit configured for receiving, by the request distributor, a first request from a network, wherein the first request relates to a delivery of a service; a sending unit configured for sending, by the request distributor, the first request to one of the at least two server computers; a server computer receiving unit configured for receiving, by the one of the at least two server computers, the first request sent by the request distributor; a determining unit configured for determining whether a further request relating to the delivery of the service is expected to be received by the request distributor; and a providing unit configured for making available distribution information to the request distributor if, in the determining unit, a further request relating to the delivery of the service is determined to be expected to be received by the request distributor.
 28. The system of claim 27, wherein the determining unit is further configured for determining that a response to the first request is to be sent by the one of the at least two server computers and that the further request relating to said service is expected to be received by the request distributor after the response is sent.
 29. The system of claim 27, wherein the distribution information identifies that the preferred or assigned destination for the further request is one of the at least two server computers.
 30. The system according to claim 27, wherein the determining unit is included in the one of the at least two server computers.
 31. The system according to claim 27, wherein the providing unit is comprised in one of the at least two server computers.
 32. The system according to claim 27, wherein the providing unit is further configured to provide the distribution information to the request distributor.
 33. The system according to claim 27, wherein the providing unit is further configured to store the distribution information in a storing unit accessible by the request distributor.
 34. The system according to claim 27, wherein the providing unit is further configured to be initiated by an operator command.
 35. The system of claim 34, wherein the operator command is a command to shutdown the one of the at least two server computers.
 36. A server computer configured for making distribution information available to a request distributor, wherein the request distributor is configured to receive requests from a network, to distribute each one of the requests to the server computer and at least one another server computer, and to use the distribution information for selecting, as a destination for each of at least some of the requests, one of the server computer and the at least one another server computer, depending on at least one attribute associated with said each request, the server computer including: a determining unit configured for determining whether a further request relating to the delivery of the service is expected to be received by the request distributor; and a providing unit configured for making available the distribution information to the request distributor if, in the determining unit, a further request relating to the delivery of the service is determined to be expected to be received by the request distributor.
 37. The server computer of claim 36, wherein the determining unit is further configured for determining that a response to a first request is to be sent by the server computer and that the further request relating to said service is expected to be received by the request distributor after the response is sent.
 38. The server computer of claim 36, wherein the distribution information identifies that the preferred or assigned destination for the further request is one of the server computer and the at least one another server computer.
 39. The server computer according to claim 36, wherein the determining unit uses at least one of: the first request, the service, the type of service, the characteristics of the service, and the reached stage in the delivery of the service.
 40. The server computer according to claim 36, wherein the providing unit is further configured for providing the distribution information to the request distributor.
 41. The server computer according to claim 36, wherein the providing unit is further configured for storing the distribution information in a storing unit accessible by the request distributor.
 42. The server computer according to claim 36, wherein the providing unit is further configured to be initiated by an operator command.
 43. The server computer of claim 42, wherein the operator command is a command to shutdown the server computer.
 44. A request distributor configured for distributing requests to at least two server computers, wherein the request distributor is configured to receive requests from a network and to distribute each one of the requests to one of at least two server computers, and at least one of the at least two server computers is configured to make available distribution information to the request distributor, the request distributor including: a receiving unit configured for receiving a first request from the network, wherein the first request relates to a delivery of a service; a sending unit configured for sending the first request to one of the at least two server computers; the receiving unit being further configured for receiving a further request relating to the delivery of the service; and a selecting unit configured for selecting as a destination for the further request, one of the at least two server computers, by using distribution information made available by one of the at least two server computers to the request distributor; and depending on at least one attribute associated with the further request, the sending unit being further configured for sending, by the request distributor, the further request to the server computer selected by the selecting unit.
 45. The request distributor of claim 44, wherein the distribution information identifies that the preferred or assigned destination for the further request is one of the at least two server computers.
 46. (canceled) 